Workflow management is a rapidly evolving technology that many businesses in a variety of industries utilize to handle business processes. A business process, as defined by the Workflow standard—Terminology & glossary, Technical Report WFMC-TC-1011, Worflow Management Coalition, June 1996. Versions 2.0., is simply a set of one or more linked activities that collectively realize a business objective or a policy goal, typically within the context of an organizational structure defining functional roles and relationships. A workflow is defined as the automation of a business process, in whole or in part, during which documents, information, or activities are passed from one participant to another, according to a set of predefined rules. A workflow management system (WfMS) defines, creates, and manages the execution of workflows.
Examples of workflow software include BusinessWare software, available from Vitria Technology, Inc. of Sunnyvale, Calif., Inconcert software, available from TIBCO Software, Inc. of Palo Alto, Calif., MQ Series software, available from International Business Machines Corporation (IBM), of Armonk, N.Y., and Staffware 2000, available from Staffware of Berkshire, United Kingdom.
In most workflow management systems (WfMS), the progression of a workflow is synchronous (i.e., as soon as an activity is completed, other activities can be started by the WfMS according to the execution dependencies specified in the workflow definition). However, there is frequently the need of specifying activities that, in order to be started, need to wait for an event to occur. For instance, an activity “Pay Employees” should start on the scheduled payday. As another example, the activity “Repair Car” should start when the event “Car Accident” is detected. Hence, these activities are not only activated due to the completion of a previous activity, but also due to the occurrence of a certain event. In this regard, it is desirable for there to be a mechanism that facilitates the activation of workflow activities based on the occurrence of certain events.
Some products acknowledge the utility of having event-based workflow execution. For example, Staffware 2000 allows for a workflow to suspend execution until the occurrence of an event. Unfortunately, this event must be manually programmed by a workflow designer. As can be appreciated, it is both time-consuming and inconvenient to require a workflow designer to write software code that generates an event corresponding to a specific instance of a business process that may or may not even be in the same enterprise as the current workflow.
Another shortcoming of the Staffware 2000 product is that it does not appear to support nodes that can send events. Consequently, Staffware 2000 product does not have a uniform and homogeneous mechanism for synchronizing with other workflows. In other words, coordination between two workflows cannot be automatic since one communication leg is missing and not supported.
Another disadvantage of the Staffware 2000 approach is that since send nodes are not supported, it cannot send events that carry values taken from the state of a workflow. Consequently, the Staffware 2000 approach does not provide a uniform and homogeneous mechanism for exchanging information with other workflow. In other words, data exchange between two workflows cannot be automatic since one communication leg is missing and not supported.
Moreover, Staffware requires the application that notifies an event to determine exactly which process instance is to be the recipient of the event. As can be appreciated this task is difficult and time consuming because new instances are created and destroyed continuously.
Consequently, it is desirable for there to be a facility to automatically sychronize activities and exchange data between workflows.
Furthermore, most workflow management systems (WfMSs) only support the separate and independent execution of business processes. However, business processes in reality need to interact with each other. For example, two business processes may need to synchronize the execution of their activities, to exchange process data, or to notify the progress in the process execution. Recent market trends increase the need for cooperation and interaction not only between different processes within a single organization, but also between different processes executed in different organizations.
In this regard, it is desirable for there to be a mechanism that facilitates inter-enterprise communication between workflows and between a workflow and other applications. As can be appreciated, the need to have workflows interact and cooperate across different organizations pose numerous challenges to prior art workflow systems.
Based on the foregoing, there remains a need for a method and system for a mechanism to provide event-based scheduling for workflow activities that overcomes the disadvantages set forth previously.